…xit-handling

Resolve conflicts:
- pyproject.toml / __init__.py / uv.lock: keep 2.3.0 (supersedes main's 2.2.93)
- CHANGELOG.md: keep both — 2.3.0 on top, then 2.2.93/2.2.92/2.2.91 from main
Dependency bumps from #207 (idna 3.15, urllib3, etc.) carried through;
uv lock --check passes.

Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>

* ci: skip PR Preview and Version Check on Dependabot PRs

Both workflows failed on every Dependabot PR for reasons that don't apply to
dependency bumps:

- PR Preview publishes a dev build to Test PyPI + Docker Hub. On a dependency
  bump there's no version change, so the publish 400s ("File already exists")
  -- and it needs publish secrets a Dependabot PR shouldn't carry anyway.
- Version Check requires an incremented app version, but Dependabot PRs touch
  uv.lock / pyproject.toml without bumping socketsecurity's version, so the
  check always fails.

Add a job-level `if` to skip each on `dependabot[bot]`-authored PRs (same
pattern already used for e2e-test.yml). Job-level skips report as "skipped"
rather than blocking, and these stay required for human-authored PRs.

Follow-up to #207 (the Dependabot review hardening), addressing fallout
observed once that config went live on real Dependabot PRs.

Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>

* ci: pin sfw uv sync to the locked dependency set on Dependabot review

`sfw uv sync` is the intended way to route uv through Socket Firewall (per
Socket's own uv-wrapper guidance), so the python-sfw-smoke job was already
exercising the firewall -- uv's integration is just quieter than npm/pip
(no "N packages fetched" footer), which made it look like a no-op.

Add `--locked` so the check verifies the exact uv.lock set and fails on
lockfile drift instead of silently re-resolving to newer versions than the
PR locked. This makes the firewall inspect precisely what would be installed
and aligns with the deterministic-verification guidance for uv-based repos.

Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>

* ci: use official socketdev/action for Socket Firewall setup

Replace the hand-rolled `npm install -g sfw` in all three sfw smoke jobs with
the official setup action (socketdev/action@v1.3.2, mode: firewall-free).

Why:
- It's the documented GitHub Actions integration for Socket Firewall Free and
  wires up sfw routing correctly, rather than relying on an ad-hoc global npm
  install. This is the right mitigation for the class of Wrapper-Mode routing
  gaps where sfw can fail to proxy fetches from files.pythonhosted.org
  (tracked upstream as ENG-4871) -- exactly the "no interception" symptom that
  made the python job look like a no-op.
- The Python jobs no longer need actions/setup-node at all (the action
  provides sfw directly), so those steps are dropped; the npm fixture job keeps
  setup-node since `npm install` needs it.

Setup mode is firewall-free (anonymous, no API token) -- unchanged, and the
reason this is safe to run on Dependabot/untrusted PRs.

Our setup is Wrapper Mode + free edition + no CodeArtifact, so the Registry
Mode + CodeArtifact `uv sync`/`uv lock` issue (CE-171) does not apply.

Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>

* ci: factor Socket Firewall setup into a composite action

The three sfw smoke jobs (python / npm-fixture / pypi-fixture) repeated the
same setup: toolchain bootstrap + socketdev/action install. GitHub Actions
doesn't support YAML anchors, so extract the shared setup into a local
composite action instead.

- New .github/actions/setup-sfw: optional Python/Node/uv toolchain inputs +
  the socketdev/action (firewall-free) install.
- Each job now just declares the toolchain it needs (`uv`, `node`, or
  `python`) and runs its own distinct sfw command.

Net effect: the pinned socketdev/action SHA now lives in ONE place (future
bumps touch a single line), the per-job setup-python/setup-node duplication
is gone, and each job body is reduced to its actual firewall check. No
behavior change.

Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>

* ci: speed up and de-duplicate the release & preview pipelines

Performance (PR preview, the iterative-feedback path):
- Add a concurrency group with cancel-in-progress so pushing a PR again
  cancels the superseded (slow) preview run instead of letting it churn.
- Build preview images amd64-only. arm64 under QEMU emulation was the
  slowest part of the job, and preview images are for quick testing;
  release/stable keep multi-arch.
- Enable GitHub Actions Docker layer cache (type=gha) on all image builds
  so unchanged layers are reused across runs.

De-duplication (GitHub Actions has no YAML anchors, so use composite actions):
- New .github/actions/setup-docker-publish: the QEMU + Buildx + Docker Hub
  login trio, shared by release.yml, pr-preview.yml, and docker-stable.yml.
  These had drifted to three different pinned SHA sets; now there is one.
  (Docker Hub creds are passed as inputs since composite actions can't read
  secrets directly.)
- New .github/actions/setup-hatch: the pinned virtualenv/hatchling/hatch
  install shared by release.yml and pr-preview.yml.

No behavior change to what gets published; only how the pipelines are
assembled and how fast/parallel they run.

Stacked on #217 (lelia/fix-dependabot-checks) to avoid a pr-preview.yml
conflict with that PR's Dependabot skip; rebase onto main once #217 lands.

Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>

* ci: pin all GitHub Actions to latest release SHAs with version comments

Bump every third-party action to its latest git-tagged release, pinned to
the resolved commit SHA with a trailing '# vX.Y.Z' comment for readability:

  actions/checkout              -> v6.0.2
  actions/setup-python          -> v6.2.0
  actions/setup-node            -> v6.4.0
  actions/github-script         -> v9.0.0
  pypa/gh-action-pypi-publish   -> v1.14.0
  docker/setup-qemu-action      -> v4.1.0
  docker/setup-buildx-action    -> v4.1.0
  docker/login-action           -> v4.2.0
  docker/build-push-action      -> v7.2.0
  socketdev/action              -> v1.3.2 (comment only)

Applied across the setup-sfw composite action and all workflows, including
docker-stable.yml which previously used floating major-version comments.

Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>

* Keep dependabot action pins visible

* Configure Dependabot for composite actions

* Include composite actions in Dependabot review notice

* Rename Docker setup composite action

* Extend dependency review to maintainer PRs

* Use CLI Socket token for enterprise dependency review

* Restrict enterprise SFW to org members

* Use dedicated SFW token secret

* Use environment-scoped SFW token

* Gate enterprise SFW on non-fork PRs

* ci(dependency-review): bundle SFW reports as artifacts

Collect each Socket Firewall smoke job's output into an sfw-artifacts/
directory and upload it (if: always(), so the report survives even when
sfw BLOCKS an install):

  - context.txt   -- provenance (mode, manifest, PR#, head SHA)
  - sfw-*.log      -- teed firewall console output (pipefail preserves the
                      sfw exit code so a block still fails the job)
  - import-smoke.log (python jobs)
  - sfw-report.json -- the structured firewall report, copied from
                       $SFW_JSON_REPORT_PATH (the path socketdev/action
                       exports); a sfw-report-missing.txt breadcrumb is
                       written instead when no report is produced

Copy rather than redirect the JSON: socketdev/action's post step reads
$SFW_JSON_REPORT_PATH to render its job summary, so the report must stay
at its temp path. Artifacts are named per edition+manifest to stay unique
within a run. Pins actions/upload-artifact to v7.0.1.

Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>

---------

Signed-off-by: lelia <2418071+lelia@users.noreply.github.com>